Наиболее очевидная и чаще всего упоминаемая причина использования «правила двух пицц» состоит в том, что оно помогает команде оставаться динамичной и компактной. Это действительно так. Но есть и более глубокое основание эффективности правила. Если команда включает до 12 человек, то более вероятно, что каждый ее член будет внимательно относиться к коллегам.
Участники малых команд более склонны помогать друг другу и делиться информацией. Когда миссия оказывается особенно важной, люди даже способны на самопожертвование. Неудивительно, что базовое подразделение «Оперативный отряд „Альфа“» в американских войсках специального назначения состоит из 12 человек. Солдаты готовы накрыть собой гранату, чтобы спасти товарищей. Этот же принцип работает и в бизнесе. В маленькой команде специалисты по маркетингу готовы сидеть всю ночь на работе, чтобы довести до совершенства завтрашнюю презентацию коллеги. Инженеры ходят по уши в масле, лишь бы обеспечить успешный запуск экспериментального образца. Это чувство локтя чаще всего исчезает с увеличением численности команды. Когда в группе сотни человек, то, естественно, вы заботитесь о своих коллегах, но эта мысль уже не столь приоритетна. Более того, сохранять единство команды становится все проблематичнее.
Поэтому ключевой вопрос звучит так: «Сколько членов должно быть в команде, чтобы успешно выполнить поставленную задачу?» Во многих интервью я слышал рекомендации, которые попробую сейчас обобщить: «Доведите численность своей команды до минимально возможной, а потом уменьшите ее еще на одного человека». Концепция «минус один», которую я впервые услышал от гуру менеджмента Тома Питерса, заставляет оставшихся членов команды мобилизовать творческие способности. Вот с чего надо начинать. С компактности и желания работать. Если сумеете, пусть вас будет меньше десятка. Вы всегда можете увеличить команду – потом… если захотите.
Сокращайтесь и ускоряйтесь: SAP
Не так давно о SAP, софтверном гиганте со штаб-квартирой в Германии, говорили так: программное обеспечение, которое она предлагает на рынок, отказоустойчиво, но чтобы использовать его, вам придется перестроить всю свою компанию. Вероятно, это мнение имело под собой основания, но в настоящее время SAP – совершенно не та компания, какой она была всего лишь пять лет назад. Самые разительные перемены произошли в организации работы команд разработчиков программного обеспечения.
Из общей численности персонала SAP (65 тысяч человек по всему миру) примерно 20 тысяч – разработчики программ. Это люди, которые придумывают, пишут, кодируют и оформляют пакеты программных продуктов и услуг корпоративного уровня. И все 20 тысяч человек рассеяны по земному шару. Они трудятся невзирая на границы, различия в культуре и религии. Но руководители SAP понимали: опережать вездесущих конкурентов в условиях нынешнего появления новых прорывных технологий, в частности более дешевого предложения программного обеспечения как услуги, они смогут, лишь сократив время разработки новых продуктов с 14,8 месяца примерно до полугода, причем сделав это в течение ближайших трех лет. Вдумайтесь: сократить время разработки продукта почти на 60 % в компании, которой есть что защищать: 65 тысяч сотрудников (в том числе 20 тысяч программистов), 16 миллиардов долларов дохода, 90 миллиардов долларов рыночной капитализации. Нелегкое решение…
«Размышляя о том, куда должна двигаться SAP, – рассказывал мне Джим Снабе в 2013 году (тогда он был одним из CEO компании), – я не смотрел на наших основных конкурентов – компании такого же масштаба или даже больше. Вместо этого я интересовался маленькими стартапами из Кремниевой долины. Мы посетили некоторые из них, в том числе те, что занимались компьютерными играми, и обнаружили новую гибкую методологию разработки программ, заключавшуюся главным образом в создании прототипов и быстром интегрировании с пользователями».
Снабе понял, что настоящий вызов и смертельная угроза для SAP появится «снизу», а вовсе не от равноценных соперников типа Oracle или IBM. Глядя на эти маленькие шустрые фирмы, он задавал себе вопросы: «Как нам угнаться за ними? Как сократить время разработки продуктов до шести месяцев?»
Снабе решился на радикальные шаги. Он собрал своих топ-менеджеров и всех руководителей групп разработчиков, чтобы провести, по его словам, «квест[36] для лидеров». С этой целью они посещали крупные компании из других отраслей, чтобы позаимствовать новые идеи и обрести вдохновение. «Мы побывали в Intel, – рассказывал Снабе. – Мы заехали в Cisco, а еще мы посетили Porsche». Именно последний визит оказался самым полезным, поскольку Porsche удалось в четыре раза увеличить объем производства, подняв прибыльность на 19 %. Как? «Они добились этого, создав множество мини-команд, получивших полномочия постоянно совершенствовать способы управления компанией», – объяснил Снабе.
Впоследствии руководители SAP комбинировали эти две мето– дологии.
Методология 1. Рассматривайте маленькие и проворные стартапы в сфере разработки программного обеспечения, а также их (и ваших!) самых опасных конкурентов как ориентиры, указывающие, в каком направлении они собираются двигаться.
Методология 2. Рассматривайте другие крупные компании, сумевшие успешно реорганизоваться, чтобы понять, как достичь того же результата.
«Мы вернулись к исходной точке, – говорит Снабе, – и сказали: хорошо, давайте попробуем довериться нашим людям. Мы разработали стратегию, которая кардинально изменила процесс внедрения инноваций, чтобы стать более гибкими и намного более быстрыми. Для этого прежде всего потребовалось отодвинуть в сторону свою управленческую гордость и дать людям свободу. Мы должны были поверить в то, что самостоятельно они смогут найти эффективный способ решения задач быстрее, чем под присмотром руководителей из штаб-квартиры».
Это и есть ключевая идея: маленькие команды получили полномочия принимать собственные решения.
«Неважно, 8, 10 или 12 участников в команде, – говорит Снабе. – Это группа примерно из 10 человек, обладающих компетенцией принимать решения, необходимые для завершения всего цикла проекта, в том числе для обеспечения качества программного продукта, его функциональности и архитектуры. Действуя таким образом, мы, фактически превратившись в кучку стартапов, работаем по единому сводному плану».
Новая организация процесса обеспечила SAP два существенных преимущества: предпринимательский динамизм, помноженный на огромные рыночные масштабы. «Я всегда говорил, – вспоминает Снабе, – что инновации – это вовсе не превращение денег в идеи. Это превращение идей в деньги. То есть вы должны сделать намного больше, чем просто создать продукт. Его необходимо вывести на свой громадный рынок. Истинная инновация требует больших масштабов. В противном случае это просто изобретение».
